In today's web service environments, a large number of web servers often provide web services (e.g., multi-site authentication services, web-based e-mail services, content providers, metadata providers, etc.). As more and more users request web services via the Internet, and as the web services become increasingly complex, a few number of web servers would not be able to handle all of the web service requests. Thus, it is very common for a particular web service to be provided by hundreds of web servers. Adding to the fact that maintaining these hundreds of web servers by itself is a difficult job for system administrators, upgrading the web service from an existing version to a different or newer version for all of the web servers often requires tremendous effort and time. In addition, providing users access to the web service during a period in which the web service is being upgraded presents another level of difficulty for system administrators. Web services rarely go through beta testing, and version rollback frequently occurs after a different or newer version of the web service has been rolled out. In other words, users often experience a large discontinuity of the web service, which often results in large user support volume that may overwhelm support personnel.
In the prior art, upgrading a web service provided by a group of web servers commonly requires taking a number of the web servers out of service (e.g., half of the web servers), removing the older version of the web service from the web servers taken out of service, installing the newer version of the web service to the web servers taken out of service, and then putting these web servers back into service. After these web servers are put back into service, the other web servers (e.g., the other half) that still run the older version of the web service are taken out of service. The older version of the web service is then removed from these other web servers; the newer version is installed; and then these other web servers are put back into service as well. Thus, at any given point of time during the web service upgrade process, a number of web servers are out of service and not providing the web service to users. For example, if about half of the web servers are initially taken out of service to install the newer version of the web service, then there is an approximately 50% reduction in the full capacity of the web servers during the upgrade process. This reduction in full capacity can be very expensive to a web service company. Furthermore, users of the web service might experience significant server downtime. Customer support volume might increase significantly. This further contributes to less customer satisfaction with the web service.
Another disadvantage of the prior art systems and methods for upgrading a web service is that users of the web service often do not receive a consistent version of the web service. In other words, the prior art usually does not specify which version of the web service is to be provided to a particular user during the upgrade process. For example, suppose after half of the web servers have been upgraded to the newer version of the web service, a user accesses to one of these upgraded web servers. Thus, this particular user has experienced the newer version of the web service. Subsequently, before the other half of the web servers are taken out of service for upgrade, the user accesses one of these not-yet-upgraded web servers. In this scenario, the user is provided access to the older version of the web service because the particular web server that the user subsequently accesses has not yet been upgraded. This is so even though this particular user has previously “experienced” the newer version of the web service at an upgraded web server. Therefore, the conventional web service upgrades often cannot provide users a consistent web service experience throughout the period of the upgrade process.
Yet another disadvantage of presently available web service upgrades is that system administrators cannot conduct effective beta testing of the newer version of the web service on the web servers. Traditionally, beta testing is very rare in the web service world. This is because a newer version of the web service generally cannot be tested out with real users before it is deployed to the web servers. As described previously, the prior art involves taking a number of web servers out of service, removing the older version of the web service from these web servers, and then installing the newer version of the web service on these web servers. In other words, at any given point of time during the upgrade process, only one version of the web service is installed on a particular web server (i.e., either the older version or the newer version). As such, all users are forced to use the newer version of the web service prior to beta testing of the newer version with a small percentage of the users. Any error or bug in the newer version of the web service may result in an outage of the web service for all of the users rather than for a small percentage of the users. Thus, any presence of error of bug in the newer version may force a full rollback of the web service. The users may experience significant problems accessing the web service during such a full-rollback period. A full rollback may also require system administrators to uninstall the newer version of the web service from the web servers and reinstall the older version of the web service to the web servers. Such un-installation and reinstallation may be a very expensive operational process.
Authenticating the user to allow access to the web service also presents another level of difficulty, since the web service usually does not recognize the user as a prior user who had previously accessed the web service. The prior art systems and methods attempt to address this difficulty by utilizing a large set of web servers partitioned among user base to provide the web service. In this scenario, upgrading the web service to a different or newer version may involve upgrading a partition of the large set of web servers at a time, thus allowing the web servers to “recognize” each user. However, in addition to the many disadvantages discussed above, this prior art approach also reduces the possibility of capacity sharing among all users. Requiring the web servers to recognize each user as a prior user does not fully address the difficulties of a large-scale web service upgrade.
Accordingly, a solution that seamlessly upgrades a web service from an existing version to a different or newer version is desired to address one or more of these and other disadvantages.